We already had this conversation before. Half of people installing the old package last month were using PHP 7, and still more than 10% on our new package. I know people can use an older version of this package, but often people are not very competent at choosing package versions, and I don't want to put up blockers.

Please allow maintainers, contributors, and users to discuss proposed changes before closing pull requests you disagree with, @GrahamCampbell.

I oppose this change in the strongest possible terms. It's so important that testing frameworks retain a large range of supported PHP versions. We already compromised by dropping PHP 7.2 and 7.3. If we drop 7.4 too, and PHP 8.3 or 8.4 make breaking changes, and we add new features, it may be impossible to test code on both PHP 7.4 and 8.3/8.4 without a mess to support two different versions of faker. We've already seen how much a mess this was with PHPUnit - Symfony's simple phpunit should not have been necessary.

Feel like I have to agree with Graham here, it's good for dev dependencies to have a less strict restriction on PHP versions. Looking at the data; a not insignificant amount of downloads still come from <8.0, so as long as it's not a maintenance issue for us to support 7.4, let's keep it around.

That being said, let's indeed not close pull requests or issues without chance for a discussion.

@GrahamCampbell

We already had this conversation before. Half of people installing the old package last month were using PHP 7, and still more than 10% on our new package. I know people can use an older version of this package, but often people are not very competent at choosing package versions, and I don't want to put up blockers.

fzaninotto/faker only supports PHP 5 and 7, so it's only natural that there is a significant percentage of people who still use fzaninotto/faker on PHP 7.

Reasons for that percentage to go up

• people who use fzaninotto/faker on PHP 5 migrate to PHP 7
• people who use fzaninotto/faker on PHP 5 migrate away from fzaninotto/faker

Reasons for that percentage to go down

• people who use fzaninotto/faker on PHP 7 migrate away from fzaninotto/faker

I oppose this change in the strongest possible terms. It's so important that testing frameworks retain a large range of supported PHP versions. We already compromised by dropping PHP 7.2 and 7.3. If we drop 7.4 too, and PHP 8.3 or 8.4 make breaking changes, and we add new features, it may be impossible to test code on both PHP 7.4 and 8.3/8.4 without a mess to support two different versions of faker. We've already seen how much a mess this was with PHPUnit - Symfony's simple phpunit should not have been necessary.

If we drop support for PHP 7.4, we do not need to run tests for fakerphp/faker on PHP 7.4. We also do not need to support multiple versions of fakerphp/faker.

By dropping support for PHP 7.4, we - like everyone else who drops support for outdated PHP versions from their PHP packages, increase the pressure on application maintainers to update from outdated to supported PHP versions.

This is a good thing.

@bram-pkg

Feel like I have to agree with Graham here, it's good for dev dependencies to have a less strict restriction on PHP versions. Looking at the data; a not insignificant amount of downloads still come from <8.0, so as long as it's not a maintenance issue for us to support 7.4, let's keep it around.

These people can still install older versions of fakerphp/faker, and as I suggested above, by dropping support for outdated PHP versions from fzaninotto/faker, we increase the pressure on application and package maintainers to update from outdated to supported PHP versions and drop support for unsupported PHP versions.

Generally

It probably makes sense to adopt a general PHP version support policy for this package - for how long after the end of life of a PHP version do we want to support that PHP version?

I'm with Graham here. I'm all in favor of maintainers pushing the ecosystem forward by reducing PHP supported version in their libraries if they want to. Testing library, however, is a major factor in version upgrades. We need to upgrade our codebase and trust our tests will catch breaking changes or issues that would otherwise become bugs in production. If production code is being touched, it can be desired to avoid modifying tests. If test code is being touched, it can be desired to avoid modifying production code. That increases confidence and helps with upgrades.

Unless there's a relevant benefit for the package itself to upgrade, I'm inclined to think that forcing PHP upgrades on testing libraries causes more harm than good in the goal of getting projects to upgrade.

@deleugpn

The current version of fakerphp/faker continues to work even when we drop support for PHP 7.4 here, doesn't it?

Im not a favor of the drop though i would like to.

It brings us not a single benefit dropping older versions and instead of breaking the 1.x branch i'd rather work om finalizing 2.x.

If im correct the main topic there is migrating the existing locale and then we can even publish a first alfa already

@bram-pkg @deleugpn @GrahamCampbell @pimjansen

Can we agree to drop support for PHP 7.4 in 2.x?

I think if we have to change to type stuff we should yes. And from there on we can properly maintain it when we do not drag all the code ourself and a bunch of legacy

@bram-pkg @deleugpn @GrahamCampbell @pimjansen

Can we agree to drop support for PHP 7.4 in 2.x?

@localheinz To me, a feature-complete library like Faker only needs code change to make itself compatible with future versions of PHP i.e. addressing breaking changes or syntax changes.

Also, I like what Symfony does with their new major version which is an exact copy of the previous version minus deprecations-only. Tagging a 2.0 version where PHP 7.4 is no longer supported causes dependency-creep where updating a dependency forces the update of a PHP "Era" version (7.4 to 8.0). If PHP support needs to be dropped, perhaps allowing dependencies to gracefully handle package update first (2.0 with >=7.4) and PHP update second (2.1 with >=8.0) would make upgrade easier.

Overall, dropping support for a PHP version just for the sake of dropping it on a core component of test suites across the PHP community will, in my opinion, cause more upgrade distress than help the community keep up-to-date, which sounds to me the opposite of what you would like to accomplish.

@deleugpn

@localheinz To me, a feature-complete library like Faker only needs code change to make itself compatible with future versions of PHP i.e. addressing breaking changes or syntax changes.

That's an opinion, nothing more.

We have dropped support for PHP 5.4, PHP 5.5, PHP 5.6, PHP 7.0, PHP 7.1, PHP 7.2, and PHP 7.3. Where were your complaints for dropping support for these PHP versions back then? Where were the complaints of users who were put under distress then?

Also, I like what Symfony does with their new major version which is an exact copy of the previous version minus deprecations-only. Tagging a 2.0 version where PHP 7.4 is no longer supported causes dependency-creep where updating a dependency forces the update of a PHP "Era" version (7.4 to 8.0). If PHP support needs to be dropped, perhaps allowing dependencies to gracefully handle package update first (2.0 with >=7.4) and PHP update second (2.1 with >=8.0) would make upgrade easier.

Symfony is an open-source project. Unlike fakerphp/faker, Symfony is backed by a company and thousands of contributors. Core maintainers are paid by Symfony, the company. On top of that, core maintainers have sponsors. Members of the core team who work for companies like QOSSMIC (previously SensioLabs Deutschland) are getting compensated directly or indirectly by these companies to contribute to Symfony.

Symfony is also a commercial project. They want to maximize the number of users who use and lock in into the Symfony eco system.

I maintain and contribute to this project (and many others) in my spare time. I have five sponsors.

Symfony and fakerphp/faker are not the same.

Overall, dropping support for a PHP version just for the sake of dropping it on a core component of test suites across the PHP community will, in my opinion, cause more upgrade distress than help the community keep up-to-date, which sounds to me the opposite of what you would like to accomplish.

That's an opinion, nothing more. Where is your data?

The maintainer of the applications and packages who you believe will be put in distress are outsourcing their distress to the maintainers of the packages that you believe will put them in distress when they drop support for PHP versions that have reached their end of life.

As pointed out before on Twitter, there is no reason to be running PHP versions that have reached their end of life in production today, and consequently, there is no reason to support PHP versions that have reached their end of life as a package maintainer unless your goal is to maximize the number of users who use that package.

Existing users who are unable or unwilling to upgrade to PHP 7.4 can continue using current or older versions of this package. As @GrahamCampbell pointed out, they are doing it.

@localheinz hey man, I'm taking myself off this discussion and unsubscribing. You shared this thread on Twitter and asked for people's opinion. I came here to give you mine and now you're just escalating things. I know everything I said is my opinion. That's what I thought I was doing, sharing my opinion. But apparently you're not looking for people to give their opinion, you're looking for validation and support for your decision. I'm sorry I can't give you that.

I'm running PHP 8.2 on all my production applications. If this library drops support for PHP 7.4, 8.0 and 8.1 today I won't lose one second of my life worrying about it.

Good luck to everyone involved. I hope the decision that makes the best impact on the PHP community is made, regardless of what that decision is.

@deleugpn

@localheinz hey man, I'm taking myself off this discussion and unsubscribing. You shared this thread on Twitter and asked for people's opinion. I came here to give you mine and now you're just escalating things. I know everything I said is my opinion. That's what I thought I was doing, sharing my opinion. But apparently you're not looking for people to give their opinion, you're looking for validation and support for your decision. I'm sorry I can't give you that.

Im not looking for opinions. I am looking for arguments for or against dropping support for PHP 7.4.

Closing in favour of focussing on 2.0.0.

Also see #747.